home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 6⁄1⁄90 / 1372-Re RE[4] Object Styl-May90 < prev    next >
Encoding:
Text File  |  1990-06-01  |  2.4 KB  |  66 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  LOOMIS       to GUITTET1
  2.  
  3. Item    4031476                         30-May-90        06:13PDT
  4.  
  5. From:   SHEBANOW1                       Shebanow, Andrew
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE>RE[4] Object Style
  10.  
  11. Attn: MacApp Mailing List
  12. SentBy: Andy Shebanow
  13.         Reply to:   RE>RE[4] Object Style
  14. Just to add more fuel to the Object Oriented Design fire, I would argue that
  15. Gets & Sets are highly suspect in a "good" object oriented design. Although I
  16. agree with Curtis (and with Neil Goldstein, who has spent a lot of time
  17. arguing with me about such things) that data members should be kept private, I
  18. believe that one of the keys to good object oriented design is the idea that
  19. an object is a protocol, and not a data structure. Providing Gets & Sets often
  20. runs contrary to this notion, since these functions imply an underlying data
  21. structure.
  22.  
  23. Here is a simple (perhaps overly so) example: Lets say that we have a TView
  24. class, similar to the one in MacApp.  One of the things about views that we
  25. tell people is that they have a bounding box, which we'll store internally as
  26. a Rect. Using the data driven approach, we define our data, and provide Gets
  27. and Sets to access the data cleanly:
  28.  
  29. TYPE
  30. TView = OBJECT(TEvtHandler)
  31.     fRect : Rect;  { bounding box of view }
  32.  
  33.     PROCEDURE GetRect(VAR r: Rect);
  34.     PROCEDURE SetRect(r: Rect);
  35. END;
  36.  
  37. What's wrong with this? Not all that much, except that the design is being
  38. driven by its data, and not by its behavior. If you turn the problem around
  39. and specify the behavior of TView first, things come out looking a little
  40. different:
  41.  
  42. TYPE
  43. TView = OBJECT(TEvtHandler)
  44.     PROCEDURE GetBoundingBox(VAR r: Rect);
  45.     PROCEDURE SetBoundingBox(r: Rect);
  46.  
  47.    fRect : Rect;  { bounding box of view }
  48. END;
  49.  
  50. Not very different, is it? One could argue that the only difference is in the
  51. naming of the functions, which could very well have been the same if better
  52. variable names had been chosen. The key, though, is that you've taken a step
  53. away from the data, and specified the behavior first. The immediate advantage
  54. is that it doesn't matter as much what the data structure used to store the
  55. bounding box is - it is the behavior of looking at or changing the bounding
  56. box that is important. When applied on a larger scale to an entire program,
  57. the difference is a lot more pronounced.
  58.  
  59. Have fun,
  60.  
  61. Andy Shebanow
  62. DTS Emeritus
  63. Apple Computer, Inc.
  64.  
  65.  
  66.